As electronic design complexity increases in many design domains including signal integrity (SI), electromagnetic interference (EMI), manufacturing, and power, the number and type of constraints imposed on a design has grown substantially. It is now clear that a single out-of-the-box computer aided design (CAD) verification solution (or application) is not sufficient to accurately validate all design requirements for today's complex designs. Most companies have unique requirements based upon their design practices and products they are trying to deliver. Solution providers have not been able to support all these requirements due to the diverse range of customer needs and narrow applicability of each. Users have had to add extensions to their applications to cover their new design constraints. Adding user-defined extensions to verification testing has required users to either create a standalone verification test, or request the solutions provider to update a built-in verification application system to include the new test.
Standalone design specific verification has historically been left to the end user to develop and deploy using a mix of applications previously delivered by the solutions provider. Most applications have an extension language and/or a mechanism to access design data. The user would typically write a complete program which extracts the data, computes the results based on the data, and then optionally determines if the results represent a violation. The results/violations are presented in a report that rarely has links back to the actual design data which is being verified. The overall solution is not well integrated to the original application so its usefulness is limited and not very modular, so reuse is difficult.
One prior approach to generate needed extensions was a request made by the end-user for the solutions provider to update the user's existing system to support a new verification requirement. This approach only works if (1) the new verification system fits cleanly into the existing system and (2) it applies to many customers to justify the solutions provider's costs. Even if the verification system meets these two criteria, it may still not be delivered for a significant time due to resource or scheduling issues. This delay may not be acceptable in today's consumer driven marketplace.
Other factors effecting today's systems create difficulties for users requiring custom extensions. A constraint's behavior is defined in the check itself, that is, the code which computes the results also codes the constraint's behavior which necessitates running the application to access the constraint. These systems capture the constraints in a separate user interface, through a separate file, or injected via other custom software. Systems do not do a good job keeping measurements simple and coding them using a proven set of lower-level functions or predicates. The verification checks provide only lengthy batch reports that can be used to review the current implementation. In certain situations, the report may be too late and can result in significant design re-work. In situations where batch verification is necessary and acceptable, the reports generated by today's systems can be disjoint, not providing an adequate level of integration.